1. Technical Field
The present invention relates to a method for setting up a process in a computer network and in particular for the location and selection of services to provide the process. The invention also extends to a suitable network.
2. Related Art
Web Services is a phrase used to describe the way in which services can be exposed and used on a network. Web Services concern the way in which software communicates. Software can come in many forms from a simple script on a personal computer, to an application on a networked server, through to a large operational support system running on a mainframe computer. These scripts, applications and software systems are examples of software components. Web services is based on software components that allow themselves to be used by other software components
A number of technologies have matured and become standardised to allow software components to be deployed to provide a Web Service and these include: simple object access protocol (SOAP); web services description language (WSDL); Universal Description, Discovery, and Integration (UDDI).
A Web Service can be described using WSDL, it can be located using UDDI and its functionality invoked using SOAP. These three technologies are built upon the common data description standard Extensible Mark-up Language (XML). XML is a standard specification for defining the content of a computer message and provides a common way to represent the content of a message sent between one software component and another. If a software application writes its output in XML any another application capable of interpreting XML can read the output and act on it.
SOAP provides the means by which one software component can invoke the functionality of another, using message-passing between the two as the means of invocation. The specification for SOAP is a world-wide standard, administered by the W3C, currently at version 1.2 issued by the W3C in June 2004: available at http://www.w3.org/TR/SOAP or as an archive at http://www.w3.org/TR/2003/REC-soap12-part0-20030624. SOAP uses a request-response mechanism in which one software component makes a request to another software component which then provides a response. Both request aid response are transported in the form of XML documents.
XML and SOAP provide, along with HTTP, the means for one software component to invoke the functionality of another over the Internet. These technologies can be used to integrate software components over any network that supports HTTP. In order to undertake this integration, the following information is also needed:                information on all available functions, including their calling parameters,        data type information for all XML messages, including the value specifications,        binding information about the specific transport protocol to be used,        address information for locating the specified service.        
A WSDL file is an XML document that provides the information listed above about a software component. Using WSDL, a software component can integrate with any of the available functions of a Web Service. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code. WSDL is defined at http:1/www.w3.org/TR/wsdl or as an archive at http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
Web services have a wide range of applications including the provision of communications capability and services and business applications. When developing an application, it may be desirable to assess the merits of a number of software components from different sources, e.g. supplied by different companies. UDDI provides this extension to the basic Web Services technologies by allowing the means to create a registry of Web Services. This takes Web Services into the realm of companies doing business with each other over the Internet. The UDDI specification enables companies to quickly, easily, and dynamically find and transact with one another. UDDI enables a company to:                describe its services,        discover other companies that offer services,        integrate with these other services.        
UDDI registry can be used to find a desired function. A request to the registry would be for a specific function and may include other requirements such as cost limits, security needs, performance criteria, etc. The registry would then propose one or more companies that provide such a function, allowing a choice of supplier. The specifications for UDDI allow, for example, the creation and use of a registry containing information about businesses and the services they offer. The specifications for UDDI are administered by the Organisation for the Advancement of Structured Information Standards (OASIS) and are available at http://uddi.org.
In addition to UDDI registries, there are listings of publicly available Web Services
Web Services also have applications in communications networks, i.e. exposing network functionality as software services. Communications service providers can use Web Services to take advantage of the convergence of software and network technologies. For example, a video-on-demand Web Service may make use of a communication service that delivers the video stream (which may present itself as a Web Service).
Grid computing allows the pooling of resources across multiple systems and their allocation on demand to provide the quality of service typically associated with a single large mainframe or supercomputer but at a lower price/performance ratio. It works by creating a resource access framework which applications can call for allocation of resources. These resources are used by the requesting application and then subsequently released. The grid environment is inherently distributed, and may include the systems of outside organisations.
Grid implementations are typically constructed using a US-government sponsored, open source tool-kit known as Globus available at http://www.globus.org/. The relevance of this to Web Services is enhanced by a proposed standard known as the Open Grid Services Architecture (OGSA) available at http://www.globus.org/ogsa/ that defines a set of Web Services to create, terminate, manage and invoke services created from distributed resources.
The use of OGSA allows any Web Services based platform to create transient services to undertake particular functions that could range from the setting up of conference calls to the large-scale manipulation of data. These services themselves could be Web Services enabled for ease of access.
Here users access services through a service-oriented architecture (SOA.) These services are actually implemented by applications built on application server kernels that utilise grid protocols to share their resource usage. Any spare resources available can be brought together to create on-demand services though OGSA calls, again accessible through the SOA. Hence the actual customer experience will be created from an aggregation of permanent and transient services controlled through the SOA.
There is considerable interest in technical solutions that will allow the management of business processes by domain experts. An important goal is to eliminate the need for translation of business requirements into terms that can be used to specify supporting IT systems. Such translation is generally time consuming and unreliable. Relevant industry developments include service-oriented architectures (SOA) in which applications are assembled from service components in a graphical development environment and a functional specification of the business process is produced. This is exemplified by the recent release by Oracle Corporation of the Business Process Execution Language (BPEL) Designer application prototype which uses Business Process Execution Language for Web Services (BPEL4WS) to describe the structure of the application. This is an example of standardised syntax and semantics for describing and specifying business processes. Software tools are then be able to use the specification to support business process management.
The major technical problem given such an abstract process description is how to build a concrete realisation with the desired level of performance. Assuming that the process is to be composed from a set of web services, one approach could be to query a set of directories (e.g. using the UDDI—Universal Description, Discovery and Integration protocol) to find instances of the services required in the business process. The directories would be queried to find instances of all the services required by the process specification. If grid services are in use the directories could also be queried for suitable nodes to instantiate the required services on.
This approach is reasonable for business processes consisting of independent services. Each service instance can then be selected separately on the basis of its individual performance characteristics. In more complex situations the process may require the results of one or more services to be provided as input to another service which therefore cannot proceed until predecessor services have completed. Process provision may be rendered less efficient by the inclusion of slower “bottleneck” services. In addition, if a significant quantity of data must be transferred between services, the characteristics of the network connectivity between service instances can also adversely effect the performance of the desired process.
Unfortunately, the information available in web service directories typically does not include the relative locations or current performance of any of the services. For complex processes or where there is a wide choice of instances of a commonly available service, there is a large number of possible configurations. Deciding which of these are able to satisfy the desired quality of service will require the collection of much more information and complex optimisation, i.e. typically requiring a significant amount of effort.